1. Field of the Invention.
The present invention relates, in general, to enterprise computing systems and methods, and, more particularly, to a method and system that provides a high performance interface to integrate, store, retrieve and manage reference information about entities.
2. Relevant Background.
Computer systems including business systems, entertainment systems, and personal communication systems are increasingly implemented as distributed software systems. These systems are alternatively referred to as xe2x80x9centerprise networksxe2x80x9d and xe2x80x9centerprise computing systemsxe2x80x9d. These systems include application code and data that are distributed among a variety of data structures, data processor systems, storage devices and physical locations. They are intended to serve a geographically diverse and mobile set of users. This environment is complicated because system users move about the distributed system, using different software applications to access and process data, different hardware to perform their work, and often different physical locations to work from. These trends create a difficult problem in providing a secure yet consistent environment for the users.
In general, distributed computing systems must scale well. This means that the system architecture desirably adapts to more users, more applications, more data, and more geographical distribution of the users, applications, and data. The cost in money and time to switch over a network architecture that is adapted to a smaller business to one suited for a larger business is often prohibitive.
A conventional computing system uses a client/server model implemented on a local area network (LAN). In such systems powerful server computers (e.g., application servers and file servers) are used to process and access data. The requested data is then transmitted to the client computer for further processing. To scale to larger networks, multiple LANs may be internetworked using, for example, leased data lines to create a wide area network (WAN). The equipment required to implement a WAN is expensive and difficult to administer. Also, as networks become larger to include multiple LANs and multiple servers on each LAN it becomes increasingly difficult to find resources (i.e., files, applications, and users) on any one of the LANs.
As computing power continues to become less expensive, clients tend to process and store their own data, using the server primarily as a file server for sharing data with other client computers. Each software application running on the client, or the client""s operating system (OS) may save client-specific configuration data that is used by the client to finetune and define the user""s software environment at runtime.
As used herein, the term xe2x80x9cprofile informationxe2x80x9d refers to any information or meta-data used by a particular piece of hardware, software, or operating system to configure, initialize, shutdown and aide in making runtime processing decisions. The profile information may be associated with a particular application or group of applications, a particular hardware device or group of devices, as well as a particular user or group of users. Some operating systems store user profile information that is used during boot operations at application startup to tailor a limited number of the system characteristics to a particular machine user. However, this profile information is closely tied to a single machine and operating system. As a result, the profile information is not useful to a new user the first time that user logs onto a particular machine. Moreover, this information is not available to remote users that are accessing the LAN/WAN using remote access mechanisms.
Existing mechanisms tend to focus on a single type of profile information, user information or application information or hardware information. Also, because these mechanisms are very application specific they limit the number and type of attributes that can be retained. Further, the profile information is isolated and fails to indicate any hierarchical or relational order to the attributes. For example, it may be desirable that a user group is required to store all files created using a particular application suite to a specific file server. Existing systems, if such a service is available at all, must duplicate profile information in each application program merely to implement the required file storage location preference. Storage location direction based on a user-by-user or user group basis is difficult to implement and may in fact require a shell application running on top of the application suite. Even then, the system is not extensible to access, retrieve, and use profile information for a new user that has not used a particular machine before.
As in the example above, existing systems for storing configuration information lead to duplicative information stored in many locations. Each application stores a copy of its own configuration information, as does each hardware device and each user. Much of this information is identical. It is difficult to maintain consistency among these many copies in a distributed computing environment. For example, when the specified file storage location changes, each copy of the configuration information must be changed. The user or system administrator must manually track the location and content of each configuration file.
An example of the inefficiencies of these types of systems is found in the Windows 95 registry file that holds profile information but has an acknowledged tendency to bloat over time with duplicative and unused data. Moreover, the registry file in such systems is so closely tied to a particular machine and instance of an operating system that it cannot be remotely accessed and used to configure other computers or devices. Hence, these systems are not generally extensible to manage multiple types of profile information using a single mechanism. A need exists for profile information that is readily accessible to all machines coupled to a network and to machines accessing the network through remote access mechanisms.
Another complicating influence is that networks are becoming increasingly heterogeneous on many fronts. Network users, software, hardware, and geographic boundaries are continuously changing and becoming more varied. For example, a single computer may have multiple users, each of which work more efficiently if the computer is configured to meet their needs. Conversely, a single user may access a network using multiple devices such as a workstation, a mobile computer, a handheld computer, or a data appliance such as a cellular phone or the like. A user may, for example, use a full featured email application to access email while working from a workstation but prefer a more compact application to access the same data when using a handheld computer or cellular phone. In each case, the network desirably adapts to the changed conditions with minimal user intervention.
There is increasing interest in remote access systems that enable a user to access a LAN/WAN using a public, generally insecure, communication channels such as the Internet. Further, there is interest in enabling LANs to be internetworked using public communication channels. This is desirable because the network administrator can provide a single high speed gateway to the Internet rather than a remote server/modem combination for each user and expensive WAN communication lines. The Internet gateway can use leased lines to access the Internet rather than more costly business phone lines. Also, the Internet gateway can be shared among a variety of applications and so the cost is not dedicated solely to providing remote access or wide area networking. The reduction in hardware cost and recurrent phone line charges would be significant if remote users could access the LAN/WAN in this manner.
From a network user""s perspective these limitations boil down to a need to manually configure a given computer to provide the user""s desired computing environment. From a remote user""s perspective these limitations require the user to manually reconfigure the remote access computer to mimic the desired computing environment or tolerate the generic environment provided by default by the remote access server. From a network administrator""s perspective, these complications require software and operating systems to be custom configured upon installation to provide the desired computing environment. In each case, the time and effort consumed simply to get xe2x80x9cup and runningxe2x80x9d is a significant impediment to efficient use of the distributed computing environment. What is needed is a system that readily adapts to a changing, heterogeneous needs of a distributed network computing environment.
One solution to the problem of finding resources in a distributed system is to use directories. Directories are data structures that hold information such as mail address book information, printer locations, public key infrastructure (PKI) information, and the like. Because of the range of functions and different needs of driving applications, most organizations end up with many different, disparate directories. These directories do not interact with each other and so contain duplicative information and are difficult to consistently maintain.
Directory software tends to be special purpose to serve the needs of a defined set of users to access information about and stored in a defined set of data store mechanisms. For example, a DOS file system (i.e., a directory of filename:physical location information) is written to be accessible only by a particular operating system (e.g., DOS, Windows, Unix, and the like). Hence, the file system information is not accessible to computers running other operating systems. Similarly, a file system cannot be amended to serve as a directory for other types of devices (e.g., an email directory). Moreover, the functionality of a file system is rigidly fixed and is not readily extended to provide new functionality such as authentication, replication, file system logging, and the like. These types of changes require rewrite and recompile of the file system software. A need exists for a directory system that is flexible and adaptable to service a variety of user entities, store directory information about a variety of objects, and incorporate a variety of functionality at runtime.
X.500 is one current model for managing on-line directories of users and resources (Directory Services) that includes the overall namespace as well as the protocol for querying and updating it. An X.500 directory is called a Directory Information Base (xe2x80x9cDIBxe2x80x9d) and the program that maintains the DIBs is called a Directory Server Agent (xe2x80x9cDSAxe2x80x9d). A Directory Client Agent (xe2x80x9cDCAxe2x80x9d) is used to search DSA sites for names and addresses.
The protocol generally used in conjunction with X.500 is the xe2x80x9cDAPxe2x80x9d (Directory Access Protocol) and it operates over the OSI (Open System Interconnection) network protocol stack. Due to the fact that a full DAP client is difficult to implement on smaller computer systems, the LDAP, (Lightweight Directory Access Protocol) was developed.
Like X.500, LDAP is both an information model and a protocol for querying and manipulating it and the overall data and namespace model is essentially that of X.500. A fundamental difference between DAP and LDAP is that the latter protocol is designed to run directly over the TCP/IP (Transmission Control Protocol/Internet Protocol) stack, and it lacks some of the DAP protocol functions such as security. In operation, LDAP enables a user to locate organizations, individuals, and other resources such as files and devices in a network, whether on the Internet or on a corporate intranet.
In a network, a directory is used to indicate where in the network something is located. On TCP/IP networks (including the Internet), the Domain Name System (xe2x80x9cDNSxe2x80x9d) is the directory system used to relate the domain name to a specific network address or unique location on the network. If the domain name is not known, LDAP allows a user to initiate a search for, for example, an individual without knowing exactly where he is located. Simply stated, an LDAP directory is organized in a simple xe2x80x9ctreexe2x80x9d hierarchy and may consist, for example, of the following levels:
The xe2x80x9cRootxe2x80x9d directory (the starting place or the source of the tree), which branches out to
Countries, each of which branches out to
Organizations, which branch out to
Organizational units (divisions, departments, and so forth), which branches out to (includes an entry for)
Individuals (which includes people, files, and shared resources such as printers)
An LDAP directory can be distributed among many servers, and each server can have a replicated version of the total directory that is synchronized periodically. When an LDAP server receives a request from a user, it takes responsibility for the request, passing it to other DSAs as necessary, but nevertheless ensuring a single coordinated response for the user.
The Internet Engineering Task Force (IETF) is a large open international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture and the smooth operation of the Internet. IETF publishes specifications for various internet protocols including LDAP. The current LDAP protocol is specified in RFCs (Request For Comments) 1777 and 1778 while the string representation of LDAP search filters is specified in RFC 2254. The disclosures of RFC 1777, RFC 1778 and RFC 2254 are specifically incorporated herein by this reference.
Meta-directories are a partial solution that provide a directory integration to unify and centrally manage disparate directories within an enterprise. However, existing solutions are not sufficiently extensible to account for the wide variety and continuously changing set of resources for which directory information is desirable. In particular, links to external data store devices are difficult to configure and limited in variety. A meta-directory manufacturer provides a limited set of directory services (e.g., LDAP, X.500, and the like) and the user is limited to those provided services. As a result users cannot link to new data store services that become available.
Moreover, in the past, meta-directory technology has not been used to catalog meta-data of sufficiently general nature to meet the needs of a dynamically growing and changing distributed computing environment. Also, meta-directory software continues to have the disadvantages of being written to support a specific, narrow set of users working on software/hardware platforms in a manner that provides a defined, non-extensible set of functionality. What is needed is a service architecture that provides directory integration together with an ability to add links to new external data store mechanisms specified at runtime.
Briefly stated, the present invention involves a mechanism, method, and computer program product for linking a profile service instance to a plurality of external data stores. Each external data store is associated with a predefined data store connector class that describes a connector object that establishes a link and provides methods to query the associated data store. An external data store profile is created in the profile service that names the connector class. An external data store reference object is created in the profile service instance that identifies the external data store profile and a number of parameters that specify particular data desired from the external data store. A profile within the profile service instance includes an attribute that names the data store reference object. When the attribute is evaluated, the data store reference object is instantiated, optionally using parameters specified at runtime, and passed as a parameter to an instance of the data store connector class identified by the external data store profile. The external data store connector instance applies the query methods to retrieve the desired data and return the desired data to the data store reference object. The profile service instance uses the returned data as the value of the attribute.